5 Exploiting time sensitive vulnerabilities

Cuento con un usuario y las funcionalidades que tengo son de iniciar sesion y reinicio de contrasena mediante ingresando un usuario existente o un correo, el backend construye una URL con los campos de user y token

https://0a60006003e927ff81b3253f0060008e.web-security-academy.net/forgot-password?user=wiener&token=4c81477a41e9d91d681e1b557717d2705dcc123d

Posiblemente exista una verificacion por detras que compruebe si el campo de user esta relacionado a ese token

el token que se genera para el proceso de reinicio de contraseña es de una longitud constante, lo que sugiere que podría ser una cadena generada aleatoriamente o un hash de algún dato desconocido. Además, el hecho de que el token sea diferente cada vez indica que, si es un hash, debe contener algún tipo de estado interno, como un generador de números aleatorios (RNG), un contador o una marca de tiempo. Esto es importante porque podría implicar que el token no es completamente aleatorio y podría ser predecible bajo ciertas circunstancias, lo que podría representar una vulnerabilidad en la seguridad del sistema.

En repeater tab envie 2 requests en paralelo de la siguiente solicitud

POST /forgot-password HTTP/2
Host: 0a60006003e927ff81b3253f0060008e.web-security-academy.net 

csrf=zROddqG4LdBZfrANjAVwJB4G08WhOrX1&username=wiener

y en mi cliente de correo recibi 2 enlaces construidos con 2 token distintos ademas en cuanto al tiempo, ambas requests tienen un delay entre estas, por lo que se puede inferir que estan siendo ejecutadas de forma secuencial en lugar de concurrente. Al revisar las cookies se evidencia phpssessionid por lo tanto se infiere que el backend funciona en PHP. Anteriormente reconoci que utiliza PHP, en PHP hay un mecanismo de locking, que en resumen hace lo siguiente: permitir el procesamiento de 1 solicitud por sesion a la vez. Esta implementacion puede ser eludida enviando las solicitudes con tokens de sesiones distintos. Asi que nuevamente envio las 2 requests en paralelo, elimine en el browser la cookie, actualice y obtuve una nueva, la copie y pegue junto al token csrf revisando el codigo del formulario y esta vez el tiempo de envio tiene una diferencia de 1 ms asi que efectivamente se logro eludir el session lock de PHP. Posterior a ello revise el cliente email y se evidencia que los 2 enlaces construidos cuentan con el mismo token, se puede inferir que esta vez fue procesado de forma concurrente. Por lo que ahora puedo proceder a manipular el campo de user a carlos para intentar construir un enlace de reinicio de contrasena para ese usuario. Lo anterior no funciono, asi que decidi observar con mas detalle el token recibido

https://0a60006003e927ff81b3253f0060008e.web-security-academy.net/forgot-password?user=wiener&token=1f6a8be78dc785a4f99fb57f51f6ffd3fba03e3a

https://0a60006003e927ff81b3253f0060008e.web-security-academy.net/forgot-password?user=wiener&token=1f6a8be78dc785a4f99fb57f51f6ffd3fba03e3a

No hay una diferencia, pero se puede entender que hay un timestamp debido a que son iguales

Aqui hay que resaltar algo importante, no vamos a recibir 2 enlaces cuando lo enviamos en paralelo, el otro enlace se exfiltro en el email de carlos, ambos en paralelo, es incorrecto asumir que obtendras 2 como lo haria cuando envias 2 en paralelo con tu mismo usuario. Pero si es correcto asumir que no se envian en paralelo cuando existe una diferencia en milisegundos entre las 2 requests en grupo. La idea es asegurarnos de que se envie en paralelo y modificar el campo de usuario a carlos porque este deberia tener nuestro mismo token /forgot-password?user=carlos&token=d7c8af5de94d1c60857cebca3fabc62a026e572a No obstante, a veces funciona con tal diferencia, en tales casos se debe probar varias veces